3. Hintergrund: Speicherschutz und virtueller Speicher (von M. Christoph)

Nachdem der letzte Bericht wenig Reaktionen hervorgerufen hat, bis auf die
Handvoll PPC-Fanatiker, kann das Thema mit dieser Aufgabe noch weiter
vertieft werden.

Zuerst muß ich meine Aussage bezüglich MorphOS korrigieren, wie mir Ralph
Schmidt mitteilte. Die angebotene Möglichkeit auf Klarstellung hat er
jedoch unbeantwortet gelassen und somit seine Chance auf die
Richtigstellung verspielt. Und ich werde mich hüten, einen zweiten Versuch
zu unternehmen, was und wofür MorphOS nun ist.

Bezüglich des Megahertz-Werts sei noch anzumerken, daß zwar Motorola-Chips
(68k und PPC) eine stärker optimierte interne Befehlsverarbeitung aufweisen
und daher mit weniger MHz auskommen, als ihre Konkurrenten. Diese weisen
aber heute ein Vielfaches der MHz auf, wodurch sie eben mehr Rechenleistung
an den Tag legen können. Und auch ein 2GHz-PPC, der nur in den Labors
existiert, wird daran nichts ändern, da auch Intel/AMD nicht stehenbleiben.
Der Marktanteil an Motorola-Chips ist trotz des breiten Einsatz in
Industrie und Zubehörgeräten verschwindend gering - unter 10%! Desweiteren
würde ich ihn persönlich auch als rückläufig einstufen. Als Beispiel seien
Drucker und Modems angeführt, die immer weniger Eigenintelligenz aufweisen
und statt dessen immer mehr vom PC (und dessen Intel-Prozessor) vorarbeiten
lassen.
Im Massenmarkt entscheidet eben der Preis und nicht die Leistung...


* Warum Speicherschutz nie hundertprozentig funktionieren kann:

Daß ein Windows NT/XP, aber auch das stabilste Betriebssystem der Welt,
Linux, durch Unachtsamkeit oder auch mutwillig zum Absturz gebracht werden
kann, zeigt, daß es keinen hundertprozentigen Speicherschutz geben kann.
Alles was Speicherschutz tatsächlich zu leisten imstande ist, ist das
Betriebssystem am Laufen zu halten, wenn ein Anwendungsprogramm einen
Fehler verursacht. Zu einem Verlust von unmittelbar vor einem
Programmabsturz bearbeiteten Daten kann es jedoch trotzdem kommen, sofern
die betreffende Software nicht über eine automatische "Notfall-Sicherungs-
Funktion" verfügt.

Die ideale Lösung wäre daher ein "Zwischending". Auf der einen Seite das
Betriebssystem so abzuschotten, daß ihm kein Programm "schaden" kann. Auf
der anderen Seite die Daten des Anwendungsprogramms auf Festplatte cachen,
damit beim Crash eine möglichst aktuelle Version der Daten zur Verfügung
steht.

Wird ein Programm in den Speicher geladen, so bekommt es vom Betriebssystem
einen speziell reservierten Bereich zugewiesen. Das Programm kann nicht
außerhalb dieses Bereichs zugreifen, und ein anderes Programm kann nicht
innerhalb zugreifen. Sollen jetzt Nachrichten ausgetauscht werden (was
ständig notwendig ist), so wird der Wunsch an das Betriebssystem geschickt.
Dieses reserviert für den Empfänger einen Speicherbereich, kopiert die
Nachricht um und leitet es dem Zielprogramm zu usw. Dadurch wird
verhindert, daß ein Programm im Speicher eines anderen "wühlt". Daß das
Ganze natürlich seine Zeit braucht (und Speicheroperationen brauchen
relativ viel Zeit), sollte damit jedem klar sein. Mit mehr Megahertz und
schnelleren RAM-Bausteinen reduziert sich natürlich der Zeitaufwand.
Trotzdem wird oft die volle Performance benötigt. Hierfür gibt es dann
einen speziellen Speicherbereich, 'shared memory' genannt. Dieser kann von
mehreren Programmen angesprochen werden. In diesem Fall sind aber spezielle
Vorkehrungen notwendig, damit nicht zwei Programme gleichzeitig eine
Nachricht dort ablegen. Und ganz egal ob shared oder single memory
verwendet wird, können immer noch "undefinierte" Parameter in den
Nachrichten zu Problemen im Zielprogramm führen - je nach Toleranz und
Berücksichtigung des Programmierers.

Und dann gibt es noch die Gruppe der Hardwaretreiber. Diese arbeiten schon
aufgrund der Performance ohne Speicherschutz! Und genau das ist der
Schwachpunkt, unter dem aktuell auch Windows XP stark leidet. Werden
nämlich ältere Treiber unter XP verwendet, so reagieren diese oft nicht wie
gewünscht, sondern verhalten sich "unberechenbar". Das trifft prinzipiell
auch auf Linux zu, wobei aber dort das Betriebssystem trotzdem noch besser
abgeschirmt ist und eher mit "virtuellem Speicher" bzw. Speicherknappheit
zu kämpfen hat.

Wer also unter diesen Gesichtspunkten Speicherschutz verlangt, damit das
neue Betriebssystem nicht mehr abstürzt, wird enttäuscht werden. Und nur
weil es andere brauchen, um amoklaufende Programme in Schach zu halten,
kann auch ein modernes Betriebssystem noch ohne Speicherschutz auskommen.
Aber es ist eben ein "gutes" Verkaufsargument.

Wie auch immer sich die Entwickler von OS 4.0 entscheiden, muß es ein
eindeutiges für oder wider sein, aber kein "wird vorgesehen". AmigaOS hat
bereits mit der Version 2.0 vorgesehen, unixartige Dateirechte einzuführen.
Die entsprechenden Bits sind zwar seit Jahren vorhanden, aber bis heute
nicht in Benutzung. Auch Datei- und Verzeichnislinks wurden gleichzeitig
eingeführt. Erst die vielen Fehlerkorrekturen in OS 3.5/3.9 machten die
Benutzung von Links möglich - und trotzdem werden sie nur halbherzig und
nicht an allen Stellen unterstützt. Im Klartext heißt das für den Anwender,
daß Links nicht verwendet werden können. Und Speicherschutz setzt genauso
tief im System an. Eine halbherzige Einbindung ist deshalb gleichzusetzen
mit "wird niemals richtig funktionieren".


* Warum virtueller Speicher auch kein Allheilmittel ist:

Betrachtet man so manches Linux- (oder Unix- im allgemeinen) Programm, so
stellen sich dem Amiga-Programmierer oftmals die Haare zu Berge. Es werden
fortlaufend Dateihandles reserviert, die nie freigegeben werden, es wird
Speicher ohne Ende angefordert und nicht einmal überprüft, ob es
funktioniert hat. Schließlich kümmert sich ja das Betriebssystem darum, daß
Speicher ausgelagert und dem Programm ein neuer Speicherbereich
bereitgestellt wird. Und Linux soll sich am Programmende auch gefälligst
darum kümmern, daß wieder alle Ressourcen freigegeben werden. Diese
Verschwendung an Ressourcen zeigt sich auch deutlich bei
"Direktportierungen" wie z.B. mySQL oder Apache. Würden Amiga-Programmierer
auch so arbeiten, würden heutige Programme und einfache Tools nicht mehr
auf "alten" (nicht aufgerüsteten) Amigas laufen.

Ein abschreckendes Beispiel auf dem Amiga ist ArtEffect: Es verbraucht
Speicher ohne Ende und lagert zusätzlich noch ständig Daten aus. Und das
auch wenn nur ein "kleines" Bild geladen wird. Da stellt sich mir die
Frage, ob dort nur bewiesen werden soll, daß es nicht mehr ohne virtuellen
Speicher geht.

Virtueller Speicher ist somit mit Sorgfalt einzusetzen. Die notwendige
Intelligenz bei den Programmierern ist allerdings oft anzuzweifeln. Dies
führt im Endeffekt lediglich zu langsameren Programmen, da jeder Speicher
"ohne Rücksicht" reserviert und das Betriebssystem ständig aus- und
einlagern muß, was auch seine Zeit benötigt, und natürlich Platz auf der
Festplatte.

Linux-Programmierer zeigen dabei häufig auch die Unsitte, daß virtueller
Speicher ohne Ende zur Verfügung steht - so zumindest die
Programmierphilosophie.
Aber eine einfache Unachtsamkeit des Programmierers (z.B. mit einer
rekursiven Funktion) oder des Anwenders (z.B. viele große Grafiken in das
Malprogramm laden) können dazu führen, daß sowohl Hauptspeicher, als auch
der virtuelle Speicher auf der Festplatte nicht mehr ausreichen. Und dann?
Dann bleibt sogar ein Linux einfach stehen oder läuft Amok. Ein
vernünftiges Amiga-Programm hingegen meldet "zuwenig freien Speicher" und
verweigert die Operation oder startet nicht. Durch Beenden anderer
Programme kann dabei genug Speicher freigegeben werden, um das andere
Programm erneut zu starten. Und reserviert nicht jemand die letzten 100
Byte des Chip-RAMs, läuft auch das Amiga-Betriebssystem und die Workbench
absolut stabil weiter.

Nicht vergessen werden sollte auch, aus welcher Zeit und aus welchem Grund
es virtuellen Speicher gibt. "Damals", als Speicherbausteine noch teuer
waren und Rechner mit 16 MByte auskommen mußten, war virtueller Speicher
die Lösung, um übergroße Grafiken und Dokumente be- und verarbeiten zu
können. Heutzutage, wo Rechner schon mit 256 MByte und mehr ausgeliefert
werden, hat virtueller Speicher keine Bedeutung mehr und sollte deshalb
auch nicht überbewertet werden.


Betrachtet man allerdings die Größe so mancher Windows-Programme, stellt
sich mir unweigerlich die Frage, ob dort nach "Kilogramm" abgerechnet wird?
Ohne Zuwachs an sichtbaren Funktionen werden die Programme immer größer und
größer. Oder soll hier nur der Speicherbaustein-Industrie unter die Arme
gegriffen werden?

Damit sollen es für heute genug der technischen Worte sein.

Michael Christoph <michael@meicky-soft.de>